fix(jcs): enforce fail-closed RFC 8785 canonicalization - #253

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
hook-generator	Ready	Preview	Aug 1, 2026 12:37am
hub	Ready	Preview	Aug 1, 2026 12:37am
platform-picker	Ready	Preview	Aug 1, 2026 12:37am

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Deployment failed with the following error:

Resource is limited - try again in 24 hours (more than 100, code: "api-deployments-free-per-day").

Learn More: https://vercel.com/tariks-projects-e9198507?upgradeToPro=build-rate-limit

Exact-head admission status and compatibility boundary

Current snapshot (2026-08-01):

• current main: 0bdffe75b56e5cd27c0632e1ba166620da327494
• PR head: f7689145ffd24ac7c6a796ef5e621b1b674c14f5
• topology: 7 commits ahead, 0 behind; merge base equals current main
• Experiment Admission, Integration Ledger, Sovereignty Contracts, Scale OS Controls, Kernel One, Automaton-2, Automaton-3, OSV, Hadolint and the Constitutional Automaton all conclude success on this exact head.
• Gate 1 JCS anchor, the full TypeScript suite, typecheck, build, Python bridge, Rust suites, observability and six field builds passed.
• The separate informational TS Coverage Thresholds job failed inside the otherwise successful Constitutional run. It is not authority-bearing under the current ceremony, but remains unresolved tooling evidence and must not be described as green coverage.

Compatibility audit findings so far:

• the primary EventStore path already projects sequence to a decimal string before canonicalization and reconstructs BigInt only outside the integrity boundary;
• sovereignty and Scale OS sequence/fencing fields are typed as canonical decimal strings;
• open-ended boundaries such as hashValue(value: unknown), computeMerkleRootFromValues(values: unknown[]), canonicalizeScaleOSSourceObjectV1(sourceObject: unknown) and canonicalizeScaleOSPayloadV1(payload: unknown) will now reject non-JSON runtime values rather than silently coercing or omitting them. This is the intended security behavior, but every caller must explicitly project such values into ordinary JSON data.

Remaining admission conditions:

1. complete the runtime caller inventory for all direct and indirect JCS/hash entry points;
2. add compatibility tests proving supported callers project BigInt, undefined, class instances and sparse data before the integrity boundary;
3. retain negative tests proving unsupported values fail closed;
4. regenerate .claude.json through its canonical provenance generator if the final head changes;
5. either repair the V8 coverage collector or explicitly preserve its non-authoritative status without claiming coverage success.

Status: CONDITIONALLY ADMISSIBLE SECURITY REPAIR; KEEP DRAFT UNTIL CALLER COMPATIBILITY IS CLOSED. No merge authorization.

Admission status correction — caller compatibility is now a hard blocker

The fail-closed JCS implementation itself remains functionally supported by the exact-head gate set already recorded for f7689145ffd24ac7c6a796ef5e621b1b674c14f5. However, a direct caller audit has identified integrity call paths that currently pass SequenceNumber values (bigint) into hashValue, which #253 correctly rejects.

Confirmed incompatible callers on the current PR head:

• src/frame/dfa.ts: transition and certificate payloads hash SequenceNumber directly.
• src/frame/lineage.ts: computeLineageHash() hashes SequenceNumber directly.
• src/frame/topology.ts: topologyPayload() includes SequenceNumber directly.
• src/ledger/verify.ts: verifyChain() hashes the complete LedgerEntry, whose sequence field is SequenceNumber.

These are not JCS defects. They are pre-existing caller-contract violations exposed by the corrected integrity boundary. Their required classification is EXPLICIT_DOMAIN_ENCODING, using canonical unsigned decimal strings before hashing. Automatic generic BigInt coercion must not be restored.

Current surface classifications:

• hashValue(value: unknown): EXPECTED_FAIL_CLOSED; callers must supply ordinary JSON or explicit domain encodings.
• computeMerkleRootFromValues(values: readonly unknown[]): EXPECTED_FAIL_CLOSED; known string/ordinary-JSON projections are safe, non-JSON values must fail.
• Scale OS sourceObject: unknown: EXPECTED_FAIL_CLOSED at the external integrity boundary.
• Scale OS payload: unknown: EXPECTED_FAIL_CLOSED at the external integrity boundary.

Required closure before admission:

1. Replace every integrity-bound SequenceNumber with an explicit canonical decimal-string projection.
2. Add compatibility tests proving SAFE_JSON_PROJECTION, EXPLICIT_DOMAIN_ENCODING, or EXPECTED_FAIL_CLOSED for each audited surface.
3. Repeat the caller search for all hashValue / computeMerkleRootFromValues call sites and close every non-JSON path.
4. Rerun exact-head CI and regenerate the admission receipt for the new candidate SHA.

Therefore the current classification is:

BLOCKED ON CALLER COMPATIBILITY — KEEP DRAFT — NO MERGE AUTHORITY

The existing exact-head evidence remains valid only for f7689145ffd24ac7c6a796ef5e621b1b674c14f5; any compatibility patch creates a new candidate requiring new evidence.

Downstream dependency recorded: PR #258 imports canonicalizeJCS from the core module repaired here. Therefore #258 must not be admitted against the pre-#253 base. Required order: admit #253 on exact-head evidence after caller-compatibility review; rebase/replay #258 onto post-#253 main; regenerate or confirm its LifeQuest golden vector; then execute exact-head tests/typecheck. Until that sequence completes, #258 remains draft with no merge authority.